Iteratively improving an advertisement response model

ABSTRACT

There are provided systems and methods for iteratively improving an advertisement response model. A payment provider may perform operations that include training an advertisement response model using a training data set. The operations include determining that a first accuracy value corresponding to the advertisement response model is less than a accuracy value threshold. The operations further include identifying, based on executing the advertisement response model using a target data set that is different from the training data set, one or more units from the target data set for which to run the advertising campaign. The operations also include receiving one or more responses corresponding to a run of the advertising campaign with respect to the identified one or more units from the target data set and updating the training data set based on the one or more responses. The operations further include training an advertisement response model using resulting training data and repeating the operations as long as the accuracy value of the resulting model stays below the threshold or until the increase in the accuracy value with each iteration becomes unprofitable with respect to the costs of acquiring responses from further units from the target dataset.

CROSS-REFERENCE TO RELATED APPLICATION

The present application is a continuation of U.S. patent application Ser. No. 15/653,024, filed Jul. 18, 2017, which is a continuation-in-part of U.S. patent application Ser. No. 14/961,727, filed Dec. 7, 2015.

TECHNICAL FIELD

The present application generally relates to predictive analysis using website data and more specifically to predicting merchant behavior using merchant website terms.

BACKGROUND

An online service provider may offer various services to one or more merchants in connection with operation of online websites or mobile applications, such as processing payments to the merchants by consumers. For example, the payment services may be used to provide a payment to the merchant for a transaction using a consumer's payment account with the payment provider or other payment instrument (e.g., a credit/debit card, a banking account, a gift card, etc.). The payment provider may also assist the merchant with other services, such as checkout and shopping services. Such features may be implemented in a website and/or dedicated application of the merchant through software development kits and/or other processes offered by the payment provider. However, in order to implement these systems into a merchant's website or application, the payment provider and merchant must be aware of each other and their corresponding systems. For example, the merchant must be aware that the payment provider offers certain payment processes. Moreover, in order to provide targeted advertising to the merchant of the payment provider's services that would be ideal for use in the merchant's shopping experience, the payment provider must have knowledge of the merchant's current systems and offerings. While general advertising by the payment provider may assist the payment provider is receiving more brand recognition, merchants may still be unaware of all of the features of the payment provider that may optimize the merchant's shopping experience to consumers. Furthermore, merchants may not be aware of how to change their website or consumer experience to increase effectiveness of the website.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram of a networked system suitable for implementing the processes described herein, according to an embodiment;

FIG. 2 is a representation of two example merchant website interfaces for use in determining a dictionary of website terms and providing targeted advertisement of payment services, according to an embodiment;

FIG. 3 is an exemplary system environment having merchant website servers with data necessary for determining a dictionary of website terms and providing targeted advertisement of payment services, according to an embodiment;

FIG. 4 is a flowchart of an example process for predicting merchant behavior using merchant website terms, according to an embodiment;

FIG. 5 is a block diagram of a networked system suitable for improving an advertisement response model, according to a particular embodiment;

FIG. 6 is a flow chart that illustrates a method for improving an advertisement response model, according to a particular embodiment; and

FIG. 7 is a block diagram of a computer system suitable for implementing one or more components in FIG. 1, according to an embodiment.

Embodiments of the present disclosure and their advantages are best understood by referring to the detailed description that follows. It should be appreciated that like reference numerals are used to identify like elements illustrated in one or more of the figures, wherein showings therein are for purposes of illustrating embodiments of the present disclosure and not for purposes of limiting the same.

DETAILED DESCRIPTION

Provided are methods utilized for predicting merchant results using merchant website terms. Systems suitable for practicing methods of the present disclosure are also provided.

A service provider, such as a payment provider, may offer services to various merchants for use by the merchants to provide a shopping experience to consumers. Various services offered to merchants may include shopping interfaces and/or marketplaces that may assist the user in finding one or more products, goods, and/or services (referred to herein as an “item” or “items”) for sale by the merchant. The processes may further include checkout and payment processes that may be used to select items for purchase, generate a transaction for the items, provide payment for the items, and arrange delivery, pick-up, or other retrieval of the items by the user. Such processes may be offered by back-end processing systems of the payment provider (e.g., server and/or database components and processing features), as well as features that may be implemented into a website or dedicated application of the merchant through software and other processes or information provided by the payment provider. In other embodiments, different service providers may also use similar processes as those described herein to provide various services to merchants or other entities.

The payment provider or other service provider may wish to advertise or otherwise market their services to existing and/or prospective customers of the payment/service provider. For example, customers of a payment provider may correspond to merchants utilizing the payment provider's services. In order to determine which merchants to advertise the payment provider's services and systems to, the payment provider may process website data for the payment provider's current merchant customers. The website data may correspond to a website of the merchant having text, images, and other data represented on the website of the merchant. In various embodiments, the payment provider may also further use data taken from a dedicated application (e.g., mobile device application) of the merchant. The payment provider may thus scan the websites (and/or dedicated applications) of the current merchant customers for the payment provider to pull the website data for processing. Once pulled, the payment provider may parse the data to determine text and other terms included on the merchant websites (and/or dedicated applications). The terms may include terms used by the merchant on their website, such as sales information for one or more items, payment and checkout information and process descriptions, and/or other merchant information appearing on the websites. The terms may also include text and information entered by users (e.g., the merchant's customers) to the website, including product reviews, forum postings, messages, service requests, and other types of information submitted by users to the merchant's website. The terms may correspond to a single text element, such as a character or word, as well as multiple text elements (e.g., a sentence). In various embodiments, the terms may further include visual images appearing on the merchant website, as well as logos and other graphics. Such images may be processed using image processing techniques to determine the content of the image, or may be matched to pre-existing images, such as similar logos, banners, and graphics used by merchants, payment providers, customer users, and/or service providers.

Once processed, the payment provider may determine a dictionary of terms occurring on the merchants' websites. The dictionary may include rankings of how often terms appear on the websites, on a percentage of the websites that the terms appear, and/or other analytic associated with the appearance of the terms on the merchant websites. The terms may provide an indication of the term's importance or prevalence of appearance on the merchant websites. For example, a term A may occur on every merchant website so that the term A provides a good indication that a website having the term would also be a merchant and potential customer of the payment provider. Similarly, a term B may occur multiple times on a medium to high percentage of the merchant websites (e.g., 75%) so that the term B also indicates that other website may be a potential merchant customer of the payment provider. In contrast, a term appearing only a few times and/or on a low percentage of the websites may not be indicative of a potential merchant customer of the payment provider. Thus, the number of times the term appears on a single website and across a plurality of merchant's websites may be important. In other embodiments, other data for the term may also be used to score or rank the term, or may provide other indications of how well the term performs in predicting behavior of other prospective merchant clients based on their website data. For example, the placement of a term on the website may be important (e.g., on the front webpage of a website or a sub-page of the website), a size or font of the term (e.g., terms with large size or prominent fonts so as to be visible), a color of the term, and/or a ratio of the term to other terms and elements on the website (e.g., if the term appears in a high ratio or where the term may appear in a low ratio due to a high volume of text and other terms presented on the website). The website data may also be pulled from previous merchant customers of the payment provider.

The payment provider may also determine a total payment volume by the merchant, which may correspond to a number, amount, and/or frequency of payments to the merchant by users (e.g., customers of the merchant). The total payment volume may be used to determine rankings for the merchants and how often the merchants use the payment provider or how much of the payment provider's systems the merchants use. The payment provider may also review each individual merchant to determine the payment processing services and other services/features of the payment provider that the merchant uses. Using this data, the payment provider may also correlate the terms with types of merchants and/or payment services used by the merchants. For example, a term C may be used on most or all of the merchant websites corresponding to merchants having a high total payment volume or a payment volume over a certain set threshold. Thus, the occurrence of term C on another new website may indicate that the new website may behavior similarly to the websites of current merchant customers of the payment provider and therefore have a similar total payment volume. In further embodiments, a term D may appear on most or all of the websites of current merchant customers of the payment provider that utilize a payment process A for transactions and payment processing. Thus, another new website having term D may indicate that the other new website may similarly wish to use the payment process A as the current merchant customers of the payment provider.

In various embodiments, the payment provider may update the dictionary of terms and their corresponding information (e.g., occurrence, importance, score, associated total payment volume, and/or associated payment processes) based on new information retrievable by the payment provider. For example, the payment provider may scan the current and/or previous merchant customers' websites to determine new terms and/or update terms already in the dictionary. The payment provider may also add new and/or prospective merchant websites into the dictionary, particularly if the prospective merchant becomes a customer of the payment provider (e.g., purchases and/or implements the payment provider's processes). The dictionary may also use historical information for the websites and/or with the payment provider, which may include when merchants became a customer of the payment provider, updates to websites and added/removed content, and other data. The term usage may be country and/or language specific, and may be weighed differently based on the country/language. For example, a term D may be more important or prevalent to English websites in one country over another. However, as processing of the terms depends only on their occurrence, importance, and/or associated total payment volume/payment processes, the dictionary generated using the website data may be independent of word definitions and language semantics, and may also function in any language through processing of term appearance, importance, and/or merchant analytics.

Once the dictionary of terms is determined using the websites of current merchant customers for the payment provider, the payment provider may retrieve website data from prospective merchants. In various embodiments, a merchant may wish to know which payment processes are ideal for the merchant based on the website data for past and current merchants using the payment provider. Thus, the prospective merchant may request that the payment provider scan the website of the prospective merchant. However, in other embodiments, the payment provider may retrieve the information by scanning the Internet for prospective merchant websites based on the presence of words in the dictionary.

Once merchant website data for a prospective merchant is retrieved, the merchant website data may be processed using the dictionary of terms to determine whether any terms appearing on the prospective merchant's website match the terms in the dictionary. For example, the payment provider may perform matching on the terms on the prospective merchant's website (e.g., front webpage and/or sub-webpages constituting the merchant website) to the terms in the dictionary of terms. Thus, the payment provider may perform analytics on the prospective merchant and predict behavior of the merchant based on the appearance of terms on the prospective merchant's website that match the terms in the dictionary. The payment provider may determine whether the merchant may have a high total payment volume based on the appearance of one or more terms associated with merchants having a high total payment volume on the website of the merchant. In other embodiments, the payment provider may determine payment services of the payment provider or other services offered by the payment provider that the prospective merchant may wish to implement in their website based on services used by merchants having matching website terms to the terms on the website of the prospective merchant. The occurrence of terms on the prospective merchant's website may also be scored against the dictionary of terms. For example, the number of appearances, the ratio appearances to other text and terms, the size, the color, the placement, and/or other information for the term may all be used to score how important the term is and how prevalent the term appears on the prospective merchant's website.

In various embodiments, a dedicated application of the prospective merchant may instead be processed against a dictionary of terms for dedicated applications of past and current merchant customers of the payment provider. Thus, the algorithm to determine the dictionary of terms may be different depending on whether the payment provider wishes to create a dictionary for mobile applications, websites, or other electronic merchant portals. In this regard, the algorithm may judge the technology behind the interfaces presented (e.g., the websites, applications, and/or other interfaces), for example, by weighing keywords and other scraped information depending on the type of information. The analytics and weighing for a word or other term may be different for the same term based on whether the term appears on an application interface or a website interface. Thus, the dictionary may be platform specific and rely on terms used within the application or website, or may be platform agnostic and rely instead on term usage. The prospective merchant may be determined based on the dictionary of terms specific to the type of interfaces processed for the prospective merchant.

In various embodiments, the dictionary of terms may also be subdivided to a type of merchant, items sold, size of merchant, or other relevant merchant metric. For example, the dictionary of terms may include groupings of large merchants, merchants who sell a certain type of good (e.g., consumer electronics), local merchants, national/worldwide merchants, service providers, digital goods providers, physical items providers, etc. Using the grouping of the merchant, the dictionary of terms may be specific to sub-types of merchants, and may be used to determine the prospective merchant matching characteristics of the sub-type of merchant. For example, the payment provider may search for prospective merchants matching large merchants, electronic device merchants, etc. The payment provider may then determine the prospective merchant is that specific type of merchant, and may tailor analytics and advertisements to that type of merchant.

Once the prospective merchant is determined, the prospective merchant's total payment volume, and/or services for use by the prospective merchant, the payment provider may determine one or more advertisements or other messages to communicate to the prospective merchant. The message(s) may generally advertise the payment provider's services to the merchant. In other embodiments, the message(s) may include targeted advertisements, which may include information on predictive analysis of the merchant as compared to other merchants having similar website terms. For example, the message(s) may include information on the type of payments the merchant may be expected to receive through the website and/or the type of payment processing required by the merchant based on the similar merchants from the dictionary of terms. Thus, the message(s) may advertise the payment provider's services and other products that may be ideal, best, or most preferable in handling these types of payments or other required services. In other embodiments, the message(s) may include advertisements for payment processes used by the similar merchants determined from the prospective merchant's website terms and the dictionary of terms. In still further embodiments, the message(s) may include behavioral and predictive analytics to the merchant based on the behavior and other analytics of the past and current merchant customers of the payment provider having matching website terms to the website of the prospective merchant. In other embodiments, the payment provider may instead provide a message to a current and/or prospective merchant, where the message alerts the merchant of analytics of terms and term information for similar merchants. The payment provider may choose the information for the similar merchants based on a success rating of the merchant (e.g., total payment volume) or other metric in order to alert the prospective or current merchant of better practices. In various embodiments, the payment provider can suggest to a current customer/merchant that certain words/terms should be changed, moved, etc.

The merchant may respond to the advertisement, such as by declining to purchase the service, enroll in the service, or use the payment provider. Further messages to the prospective merchant and other prospective merchant's may be tailored to the response, for example, by removing advertised material that the prospective merchant responded poorly to or declined. The further messages and advertisements may provide the next best services based on the merchant's total payment volume and/or similar merchants. Where the prospective merchant accepts the offer and utilizes a service of the payment provider, the payment provider may assist the merchant in implementing the service into the merchant's website and/or dedicated application. Moreover, the payment provider may update the dictionary with information for the prospective merchant and the prospective merchant's response, who has now become a current merchant customer to the payment provider.

According to other embodiments, the payment provider may also be configured to improve an advertisement response model. Given a target data set, the advertisement response model may be configured to predict the responses of units included in the target data set to a particular advertising campaign. As used herein, a “unit” of a data set may correspond to a user of the payment provider, a prospective user of the payment provider, or any prospective customer, including but not limited to, consumers and merchants and prospective consumers and merchants. Further, a “target data set” may include units whose responses to the advertising campaign are unknown. A “training data set” may include units whose responses to the advertising campaign are known.

Based on predicted responses output by the advertisement response model, the payment provider may target particular units in the target data set (e.g., units with positive predicted responses) for the advertising campaign. Further, by applying a model enhancement process described in more detail below, the payment provider may be able to improve the advertisement response model. For example, the model enhancement process may improve the advertisement response model's accuracy in predicting the responses of the units included in the target data set. Various types of advertisement response models may be improved by the model enhancement process including, but not limited to classification algorithms such as AdaBoost classifier, logistic regression, support vector machines, gradient boosting classifier, Isolation Forest, linear discriminant analysis, neural networks (e.g., multi-layer perceptron), decision trees classifier, Random Forest classifier, naïve Bayesian classifier, and Bagging classifier.

In some examples, the model enhancement process begins with the payment provider executing the advertisement response model using a training data set. In other words, the advertisement response model may be trained based on the training data set. The training data set may include one or more units, and the training data set may also indicate known responses to the advertising campaign for each unit of the one or more units (e.g., how each unit responds to the particular advertising campaign). In some cases, responses may be categorized by response types. For instance, the response types may include a positive response (e.g., a user or potential user buys or would buy the product or service offered by the advertising campaign) or a negative response (e.g., a user or potential user does not or would not buy the product or service offered by the advertising campaign). However, it will be appreciated that in other embodiments, any number of response types (including more or fewer response types) may be indicated by the training data set.

In certain embodiments, the training data set may be a previously existing training data set that is provided to the advertisement response model. In other embodiments, the training data set may be generated as part of the model enhancement process. To this end, various techniques and methods may be used in order to develop the training data set. For example, the training data set may be generated based on a run of the advertising campaign with respect to a random sampling of a particular population. As such, the responses of each unit of the random sampling of the population to the advertising campaign may be stored in the training data set. It will be appreciated that other methods of generating the training data set are also contemplated.

Subsequent to training the advertisement response model using the training data set, the payment provider may determine an accuracy value corresponding to the advertisement response model. In certain embodiments, the accuracy value may be calculated as part of executing the advertisement response model. The accuracy value may indicate an accuracy of the advertisement response model in predicting the response of units in a particular data set to the advertising campaign. According to a particular embodiment, the accuracy value may include numbers or ratios. In some embodiments, the accuracy value may correspond to a ratio. For example, the advertisement response model may predict a particular data set to have a positive outcome with respect to the advertising campaign. The accuracy value may be a ratio of the number of units in the particular data set that actually have a positive outcome as a result of running the advertising campaign versus the total number of units in the subset of the particular data set that the model has predicted to have the positive outcome.

In certain implementations the payment provider may determine that the accuracy value is less than a accuracy value threshold. In response to determining that the accuracy value is less than the accuracy value threshold, the payment provider may execute the advertisement response model using the target data set. The target data set may be different than the training data set, and in some cases, may be significantly larger than the training data set. Based on the execution of the advertisement response model using the target data set, the payment provider may calculate a certainty score corresponding to each unit of the target data set. For example, in certain embodiments, the certainty scores may be an output of executing of the advertisement response model using the target data set.

Based on the certainty scores, the payment provider may select a subset of the target data set. For example, the payment provider may select the subset based on the subset having relatively low certainty scores. The low certainty scores may indicate that the advertisement response model is relatively uncertain with respect to predicting how the units in the subset would respond to the advertising campaign. According to a particular embodiment, the payment provider may rank the units of the target data set according to their respective certainty scores. As such, the selected subset may include a predetermined number of lowest ranked units in the target data set (e.g., the units having the lowest certainty scores). For example, the payment provider may select 200 units with the lowest certainty scores to be included in the subset. According to another particular embodiment, the payment provider may select the subset to include any unit having a corresponding certainty score that is below a certainty score threshold.

Further, a run of the advertising campaign may be performed using the selected subset of the target data set. Based on the run, one or more responses to the advertising campaign may be associated with the units in the subset and provided to the payment provider. Since the units in the subset are now associated with known responses, the payment provider may update the training data set to include the subset the associated responses. The updated training data set is therefore augmented by gathering actual responses to advertising campaign from units in the subset—units whose predicted responses the advertisement response model was previously uncertain about. Additionally, subsequent to receiving the responses from the subset of the target data set, the payment provider may remove the units of the subset from the target data set.

Using the updated training data set, the model enhancement process may then be repeated beginning with the payment provider executing the advertisement response model using the updated target training data set. Moreover, the model enhancement process may be repeated or iterated until a calculated accuracy value for the advertisement response model reaches or is above a accuracy value threshold. Thus, the training data set is continually improved, thereby also improving the advertisement response model until the accuracy value threshold is reached. Subsequent to determining that the calculated accuracy value reaches or exceeds the accuracy value threshold, the payment provider may execute the advertisement response model using the remaining units in the target data set (e.g., the target data set minus any subsets that have been removed from the target data set during iterations(s) of the model enhancement process). Based on execution of the advertisement response model using the remaining units in the target data set, the payment provider may determine which of the remaining units in the target data set have a positive predicted response to the advertising campaign. The advertising campaign may then be run to target the determined units that have a positive predicted response.

As shown above, using the model enhancement process, the advertisement response model may be iteratively improved. Subsets of the target data set, whose predicted responses (to the advertising campaign) the advertisement response model is relatively uncertain about, may be identified. Uncertainty about the responses of the units in the subset is mitigated by running the advertising campaign with respect to these units. From running the advertising campaign, the units' actual responses to the advertising campaign may be obtained. The units and their corresponding responses are iteratively added to an initial training data set, which is used to iteratively train the advertisement response model. In this manner, the accuracy of the advertisement response model is improved until an accuracy threshold is reached.

As a result, the model enhancement process describe above may reduce a total cost of managing the advertising campaign with respect to the target data set. For example, transmitting advertisements to different units (e.g., user devices and potential user devices) and obtaining responses to the advertisements may be relatively expensive to perform. Further, a particular unit that does not respond positively to a transmitted advertisement (e.g., does not buy the product or service offered by the advertisement), drives up the cost of transmitting the ad even further. By improving the accuracy value of the advertisement response model, the conversion rate of running the advertising campaign with respect to the units selected by the advertisement response model may also improve. Such improvement in the conversion rate may more than offset any costs associated with improving the training data set during each iteration of the model enhancement process, thereby reducing the total cost of managing the advertising campaign. The reduced costs can lead to a new breakeven point for the profitability of certain advertising campaigns. Thus, model enhancement process may make certain campaigns profitable that would otherwise have been unprofitable otherwise. Additionally, by enabling the advertisement response model to reach more customers that are interested in the products or services being advertised, customer satisfaction for the merchant and/or entity running the advertising campaign may be improved.

According to certain embodiments, the payment provider may select a particular advertisement response model for improvement based on theoretical considerations (e.g., known performance of the particular advertisement response model in similar situations, robustness), practical considerations (e.g., data availability, computational complexity of the particular advertisement response model, and/or interpretability of the particular advertisement response model), and/or data driven considerations. For example, the accuracy value of the advertisement response model and the number of advertised units (e.g., the number of units from the target data set for which the advertising campaign has been run) to achieve the accuracy value may be the primary factors for determining the profitability of the advertising campaign. These parameters (e.g., the accuracy value and the number of advertised units) can be estimated on an existing dataset (e.g., from past advertising campaigns) where the outcomes of the past advertising campaigns are already known. The payment provider can also measure the parameters dynamically during an advertising. For example, multiple advertisement response models can be used to drive a single advertising campaign in parallel and as a particular model or a group of the models is showing better results relative to the other, the particular model or group of models may be provided a larger share of data from both the training data set and the target data set.

FIG. 1 is a block diagram of a networked system 100 suitable for implementing the processes described herein, according to an embodiment. As shown, system 100 may comprise or implement a plurality of devices, servers, and/or software components that operate to perform various methodologies in accordance with the described embodiments. Exemplary devices and servers may include device, stand-alone, and enterprise-class servers, operating an OS such as a MICROSOFT® OS, a UNIX® OS, a LINUX® OS, or other suitable device and/or server based OS. It can be appreciated that the devices and/or servers illustrated in FIG. 1 may be deployed in other ways and that the operations performed and/or the services provided by such devices and/or servers may be combined or separated for a given embodiment and may be performed by a greater number or fewer number of devices and/or servers. One or more devices and/or servers may be operated and/or maintained by the same or different entities.

System 100 includes a user, a current merchant server 110, a prospective merchant server 130, and a payment provider server 150 in communication over a network 180. Current merchant server 110 may be established by a merchant customer (not shown) of payment provider server 150 that sets up current merchant server 110 to provide a website (and/or dedicated merchant application) to consumers that may purchase items with the merchant. For example, the website may function as a marketplace or other sales interface for consumers to view items and item information, select items for purchase, enter a checkout process, and pay the merchant. In order to provide payments, current merchant server 110 may utilize one or more processes provided by payment provider server 150. Payment provider server 150 may determine a dictionary of terms appearing on the website of current merchant server 110 and/or other merchant servers, and may associate the terms with other information for the website and/or merchant for current merchant server 110. Using the dictionary, payment provider server 150 may identify prospective merchant server 130 having a website for a prospective merchant customer (not shown). Payment provider server 150 may utilize the dictionary to provide various features and services to prospective merchant server 130.

Current merchant server 110, prospective merchant server 130, and payment provider server 150 may each include one or more processors, memories, and other appropriate components for executing instructions such as program code and/or data stored on one or more computer readable mediums to implement the various applications, data, and steps described herein. For example, such instructions may be stored in one or more computer readable media such as memories or data storage devices internal and/or external to various components of system 100, and/or accessible over network 180.

Current merchant server 110 may be implemented using any appropriate hardware and software configured for wired and/or wireless communication with communication device 130 and/or payment provider server 150. Current merchant server 110 may correspond to a device, server, or cloud computing architecture to provide sales of items, for example, through a physical merchant location and/or an online marketplace accessible over a network connection that has a corresponding physical location for retrieval of one or more sold items. Current merchant server 110 may further be used to process payments for items, provide incentives for purchase of items, advertise items, and/or allow release of items to current merchant server 110. Although a merchant device is shown, the merchant device may be managed or controlled by any suitable processing device. Although only one merchant device is shown, a plurality of merchant devices may function similarly.

Current merchant server 110 of FIG. 1 contains a website application 120, a sales application 112, other applications 114, a database 116, and a communication module 118. Website application 120, sales application 112, and other applications 114 may correspond to processes, procedures, and/or applications executable by a hardware processor, for example, a software program. In other embodiments, current merchant server 110 may include additional or different modules having specialized hardware and/or software as required.

Website application 120 may correspond to one or more processes to execute modules and associated specialized hardware of current merchant server 110 to provide a website for a merchant, which may include one or more webpages accessible over a network by a consumer in order to shop with the merchant. In this regard, website application 120 may correspond to specialized hardware and/or software of current merchant server 110 that provide a website and corresponding interfaces. The website may correspond to a merchant marketplace for the current merchant associated with current merchant server 110, or other sales interface. Website application 120 may provide the website over a network, for example, accessible using a browser over the Internet. A consumer may visit the website hosted by website application 120 to view one or more items for purchase. Moreover, the website may allow the user to select one or more of the item(s) for purchase and enter the selected item(s) to a transaction. The website may include checkout and payment processes for use in completing the transaction between the user and the merchant. The website may provide shopping, checkout, and/or payment services through payment provider server 150 and/or using services offered by payment provider server 150, for example, using sales application 112. Moreover, shopping and transaction information generated by website application 120 and using services, processes, and features provided by payment provider server 150 may be collected by payment provider server 150 to determine a total payment volume and/or other analytical information on merchant behavior (e.g., sales, payment processes used, user integration and/or satisfaction, etc.). In other embodiments, website application 120 may instead correspond to a dedicated application provided by current merchant server 110, which may provide data used by the application (e.g., retrievable through an API call of the dedicated application to website application 120).

The website provided by website application 120 may further include associated website data. The website data may be displayed on or otherwise retrievable from the website (e.g., through accessing stored database information associated with the website). The website data may correspond to information provided by the merchant on the website, such as titles, descriptions, instructions, categories, merchant information, and/or other shopping/payment information. The website data may also include information entered by consumers to or using the website. For example, the website data may include forum posts, user reviews, messages, user information, and/or other user entered data. The website data may include text, as well as text metadata (e.g., color, placement, size, font, etc.). In further embodiments, the website data may also include images, banners, logos, symbols, and other graphical elements. The website data may be retrieved by payment provider server 150, as discussed herein.

Sales application 112 may correspond to one or more processes to execute modules and associated specialized hardware of current merchant server 110 to sell one or more items offered by a current merchant customer (not shown) of payment provider server 150 and associated with current merchant server 110 through a website provided by website application 120. Sales application 112 may further provide checkout and payment processes for a transaction to purchase the items for sale from the merchant corresponding to current merchant server 110. In this regard, sales application 112 may correspond to specialized hardware and/or software of current merchant server 110 to provide shopping, checkout, and payment processes used in the website. For example, sales application 112 may provide item sales through an online marketplace using the website of the merchant. In other embodiments, sales application 112 may provide sale of items in a physical location, such as a physical merchant retail location, through the website of the merchant.

Sales application 112 may include information for a price for the item, a discount for the item, a price change for the item, and/or other incentives for items and/or with the merchant corresponding to current merchant server 110 (e.g., rebates, payments, etc.). Additionally, the sales data and other item data (e.g., inventory, status, condition, etc.) in the purchase information may be retrievable by the website of current merchant server 110, such as request-able through an API call and/or retrievable from database 116. The information may be based updated periodically or continuously, such as in real time and information for the item(s) for sale changes. Sales application 112 may be used to establish a transaction once a consumer has selected one or more items for purchase in a transaction, which may utilize checkout processes provided by payment provider server 150. Once a payment amount is determined for the transaction for the item(s) to be purchased, sales application 112 may request payment from the consumer using processes provided by payment provider server 150. Sales application 112 may receive payment processing information, such as a purchase request. In such embodiments, the purchase request may be processed, payment provided to the merchant account, and notification of payment (or failure, for example, where there are insufficient user funds) may be sent to sales application 112. The payment may be made by payment provider server 150 on behalf of the user associated with current merchant server 110. Sales application 112 may then receive the results of the transaction processing, and complete the transaction with the user, for example, by providing the user the items for the transaction or declining the transaction where the user is not authenticated or the transaction is not authorized (e.g., insufficient funds).

Current merchant server 110 includes other applications 114 as may be desired in particular embodiments to provide features to current merchant server 110. For example, other applications 114 may include security applications for implementing server-side security features, programmatic client applications for interfacing with appropriate application programming interfaces (APIs) over network 180, or other types of applications. Other applications 114 may also include email, texting, voice and IM applications that allow a merchant to send and receive emails, calls, texts, and other notifications through network 180. In various embodiments, other applications 114 may include financial applications, such as banking, online payments, money transfer, or other applications associated with payment provider server 150. Other applications 114 may contain software programs, executable by a processor, including a graphical user interface (GUI) for a website or application configured to provide an interface to consumers.

Current merchant server 110 may further include database 116 which may include, for example, identifiers such as operating system registry entries, identifiers associated with hardware of current merchant server 110, or other appropriate identifiers, such as identifiers used for payment/merchant/server authentication or identification. Identifiers in database 116 may be used by a payment/credit provider, such as payment provider server 150, to associate current merchant server 110 with a particular account maintained by the payment/credit provider. Item, sales, and/or benefit information for items sold by the merchant associated with current merchant server 110 may be stored to database 116. Database 116 may further include website data and information, including term information for terms used on or with a website for current merchant server 110.

Current merchant server 110 includes at least one communication module 118 adapted to communicate with payment provider server 150. In various embodiments, communication module 118 may include a DSL (e.g., Digital Subscriber Line) modem, a PSTN (Public Switched Telephone Network) modem, an Ethernet device, a broadband device, a satellite device and/or various other types of wired and/or wireless network communication devices including microwave, radio frequency, infrared, Bluetooth, and near field communication devices.

Prospective merchant server 130 may be implemented using any appropriate hardware and software configured for wired and/or wireless communication with communication device 130 and/or payment provider server 150. Prospective merchant server 130 may correspond to a device, server, or cloud computing architecture to provide sales of items, for example, through a physical merchant location and/or an online marketplace accessible over a network connection that has a corresponding physical location for retrieval of one or more sold items. Prospective merchant server 130 may further be used to process payments for items, provide incentives for purchase of items, advertise items, and/or allow release of items to current merchant server 110. Although a merchant device is shown, the merchant device may be managed or controlled by any suitable processing device. Although only one merchant device is shown, a plurality of merchant devices may function similarly.

Prospective merchant server 130 of FIG. 1 contains a website application 140, a sales application 132, other applications 134, a database 136, and a communication module 138. Website application 140, sales application 132 and other applications 134 may correspond to processes, procedures, and/or applications executable by a hardware processor, for example, a software program. In other embodiments, prospective merchant server 130 may include additional or different modules having specialized hardware and/or software as required.

Website application 140 may correspond to one or more processes to execute modules and associated specialized hardware of prospective merchant server 130 to provide a website for a merchant, which may include one or more webpages accessible over a network by a consumer in order to shop with the merchant. In this regard, website application 140 may correspond to specialized hardware and/or software of prospective merchant server 130 that provide a web site and corresponding interfaces. The website may correspond to a merchant marketplace for a prospective merchant associated with prospective merchant server 130, or other sales interface. Website application 140 may provide the website over a network, for example, accessible using a browser over the Internet. A consumer may visit the website hosted by website application 140 to view one or more items for purchase. Moreover, the website may allow the user to select one or more of the item(s) for purchase and enter the selected item(s) to a transaction. The website may include checkout and payment processes for use in completing the transaction between the user and the merchant. In various embodiments, the website may correspond to a prospective merchant that does not implement any services or features associated with payment provider server 150. However, the website may also provide shopping, checkout, and/or payment services through payment provider server 150 and/or using services offered by payment provider server 150. In this regard, payment provider server 150 may further process the website and associated website term data to determine additional services and analytics to offer the prospective merchant for use in the website. Moreover, shopping and transaction information generated by website application 140 may be collected by payment provider server 150 to determine a total payment volume and/or other analytical information on merchant behavior (e.g., sales, payment processes used, user integration and/or satisfaction, etc.) of the prospective merchant. In other embodiments, website application 140 may instead correspond to a dedicated application provided by prospective merchant server 130, which may provide data used by the application (e.g., retrievable through an API call of the dedicated application to website application 140).

The website provided by website application 140 may further include associated website data. The website data may be displayed on or otherwise retrievable from the website (e.g., through accessing stored database information associated with the website). The website data may correspond to information provided by the merchant on the website, such as titles, descriptions, instructions, categories, merchant information, and/or other shopping/payment information. The website data may also include information entered by consumers to or using the website. For example, the website data may include forum posts, user reviews, messages, user information, and/or other user entered data. The website data may include text, as well as text metadata (e.g., color, placement, size, font, etc.). In further embodiments, the website data may also include images, banners, logos, symbols, and other graphical elements. The website data may be retrieved by payment provider server 150, as discussed herein.

Sales application 112 may correspond to one or more processes to execute modules and associated specialized hardware of prospective merchant server 130 to sell one or more items offered by a prospective merchant customer (not shown) of payment provider server 150 and associated with prospective merchant server 130 through a website provided by website application 140. Sales application 112 may further provide checkout and payment processes for a transaction to purchase the items for sale from the merchant corresponding to prospective merchant server 130. In this regard, sales application 112 may correspond to specialized hardware and/or software of prospective merchant server 130 to provide shopping, checkout, and payment processes used in the website. For example, sales application 112 may provide item sales through an online marketplace using the website of the merchant. In other embodiments, sales application 112 may provide sale of items in a physical location, such as a physical merchant retail location, through the website of the merchant.

Sales application 112 may include information for a price for the item, a discount for the item, a price change for the item, and/or other incentives for items and/or with the merchant corresponding to prospective merchant server 130 (e.g., rebates, payments, etc.). Additionally, the sales data and other item data (e.g., inventory, status, condition, etc.) in the purchase information may be retrievable by the website of prospective merchant server 130, such as request-able through an API call and/or retrievable from database 116. The information may be based updated periodically or continuously, such as in real time and information for the item(s) for sale changes. Sales application 112 may be used to establish a transaction once a consumer has selected one or more items for purchase in a transaction. Once a payment amount is determined for the transaction for the item(s) to be purchased, sales application 112 may request payment from the consumer. Sales application 112 may receive payment processing information, such as a purchase request. In such embodiments, the purchase request may be processed, payment provided to the merchant account, and notification of payment (or failure, for example, where there are insufficient user funds) may be sent to sales application 112. Sales application 112 may then receive the results of the transaction processing, and complete the transaction with the user, for example, by providing the user the items for the transaction or declining the transaction where the user is not authenticated or the transaction is not authorized (e.g., insufficient funds). In various embodiments, some or all of the aforementioned features may be provided by payment provider server 150 or may be processed using other processes. In this regard, payment provider server 150 may attempt to advertise additional services and features to the prospective merchant corresponding to prospective merchant server 130.

Prospective merchant server 130 includes other applications 134 as may be desired in particular embodiments to provide features to prospective merchant server 130. For example, other applications 134 may include security applications for implementing server-side security features, programmatic client applications for interfacing with appropriate application programming interfaces (APIs) over network 180, or other types of applications. Other applications 134 may also include email, texting, voice and IM applications that allow a merchant to send and receive emails, calls, texts, and other notifications through network 180. In various embodiments, other applications 134 may include financial applications, such as banking, online payments, money transfer, or other applications associated with payment provider server 150. Other applications 134 may contain software programs, executable by a processor, including a graphical user interface (GUI) configured to provide an interface of a website or application to consumers.

Prospective merchant server 130 may further include database 136 which may include, for example, identifiers such as operating system registry entries, identifiers associated with hardware of prospective merchant server 130, or other appropriate identifiers, such as identifiers used for payment/user/device authentication or identification. Identifiers in database 136 may be used by a payment/credit provider, such as payment provider server 150, to associate prospective merchant server 130 with a particular account maintained by the payment/credit provider. Item, sales, and/or benefit information for items sold by the merchant associated with prospective merchant server 130 may be stored to database 136. Database 136 may further include website information and other data, such as website term data for terms used on or with a website.

Prospective merchant server 130 includes at least one communication module 138 adapted to communicate with payment provider server 150. In various embodiments, communication module 138 may include a DSL (e.g., Digital Subscriber Line) modem, a PSTN (Public Switched Telephone Network) modem, an Ethernet device, a broadband device, a satellite device and/or various other types of wired and/or wireless network communication devices including microwave, radio frequency, infrared, Bluetooth, and near field communication devices.

Payment provider server 150 may be maintained, for example, by an online service provider, which may provide connection services on behalf of users. In this regard, payment provider server 150 includes one or more processing applications which may be configured to interact with communication device 130, prospective merchant server 130, and/or another device/server to facilitate payments and payment processing. In one example, payment provider server 150 may be provided by PAYPAL, Inc. of San Jose, Calif., USA. However, in other embodiments, payment provider server 150 may be maintained by or include another type of service provider, which may provide connection services to a plurality of users.

Payment provider server 150 of FIG. 1 includes a website processing application 160, a merchant advertisement application 170, a transaction processing application 152, other applications 154, a database 156, and a network interface component 158. User connection application 170, transaction processing application 152, and other applications 154 may correspond to executable processes, procedures, and/or applications with associated hardware. In other embodiments, payment provider server 150 may include additional or different modules having specialized hardware and/or software as required.

Website processing application 160 may correspond to one or more processes to execute software modules and associated specialized hardware of payment provider server 150 to retrieve website data for a prospective merchant customer of payment provider server 150 and process the website data using website term information stored to database 156. In this regard, website processing application 160 may correspond to specialized hardware and/or software to determine that prospective merchant server 130 corresponds to a prospective merchant customer of payment provider server 150 that may wish to implement one or more processes, services, and/or features of payment provider server 150 into a web site of the prospective merchant. For example, website processing application 160 may receive a request to process the website data for the website of prospective merchant server 130. In other embodiments, website processing application 160 may instead comb or scrape available webpages and/or perform webpage searches using terms from the website term information to determine the webpage for prospective merchant website 130 is a website of a prospective merchant.

Prior to determination of the website of prospective merchant server 130 is a website for a prospective merchant customer, website processing application 160 may determine the website term information for past and/or current merchant customers of payment provider server 150. The website term information may include processed website data having texts, graphics, and/or images (e.g., terms) used on the past and/or current merchant customers of payment provider server 150 that utilize one or more service of payment provider server 150. Thus, the website data may correspond to a website of the merchant having text, images, and other data represented on the website of the merchant. In further embodiments, a dedicated application having one or more application interfaces may also be used. Website processing application 160 may scan the websites (and/or dedicated applications) of the past and/or current merchant customers (e.g., the website hosted by website application 120 of current merchant server 110) or pull the website data from a database (e.g., database 116 of current merchant server 110). Once pulled, website processing application 160 may parse the data to determine text and other terms included on the merchant websites (and/or dedicated applications). The terms may include terms used by the merchant on their website (e.g., information displayed on a front webpage and/or sub-webpages, sales, payment, checkout, merchant, and/or consumer information). The terms may also include information provided by consumers on the website, including product reviews, forum postings, messages, service requests, and other types of information submitted by users to the website. The terms may correspond to a single text element, such as a character or word, as well as multiple text elements (e.g., a sentence). The terms may also include information on usage, such as nearby terms and/or accompanying terms, placement in a sentence or paragraph, or other term information. In various embodiments, the terms may further include visual images appearing on the merchant website, as well as logos and other graphics. Such images may be processed using image processing techniques to determine the content of the image, or may be matched to pre-existing images, such as similar logos, banners, and graphics used by merchants, payment providers, customer users, and/or service providers.

Thus, website processing application 160 may determine the website term information having a dictionary of terms used on webpages of existing and/or past merchant customers of payment provider server 150 (e.g., merchants that utilize services, processes, and/or features provided by payment provider server 150). The dictionary may include one or more terms, as well as analytics for each term, such as rankings or numbers of how often terms appear on the websites, on what percentage of the websites that the terms appear, where they appear on the websites, and/or other analytic associated with the appearance of the terms on the websites. In this regard, the terms may provide an indication of the terms importance or prevalence of appearance on the merchant websites. For example, a term appearing on a high number/percentage of websites and/or having a large number of appearances may be indicated as important to determining similar merchants that may wish to use services provided by payment provider server 150. Conversely, a term appearing only a few times and/or on a low percentage of the websites may not be indicative of a potential merchant customer of the payment provider. Thus, the number of times the term appears on a single website and across a plurality of merchants' websites may be important. In other embodiments, other data for the term may also be used to score or rank the term, or may provide other indications of how well the term performs in predicting behavior of other prospective merchant clients based on their website data. For example, the placement of a term on the website may be important (e.g., on the front webpage of a website or a sub-page of the website), a size or font of the term (e.g., terms with large size or prominent fonts so as to be visible), a color of the term, and/or a ratio of the term to other terms and elements on the website (e.g., if the term appears in a high ratio or where the term may appear in a low ratio due to a high volume of text and other terms presented on the website).

Website processing application 160 may further determine a total payment volume by the merchant, which may correspond to a number, amount, and/or frequency of payments to the merchant by the merchant's consumer base. The total payment volume may indicate the merchant's performance and well as the payment services of payment provider server 150 that would be ideal for the merchant. Website processing application 160 may also determine the payment processing features and services that each merchant uses. The aforementioned data may be paired with the website term information to associate total payment volumes and/or payment processes with various website terms.

In various embodiments, website processing application 160 may update the dictionary of terms and their corresponding information (e.g., occurrence, importance, score, associated total payment volume, and/or associated payment processes) based on new information retrievable from each merchant website. Website processing application 160 may also add new and/or prospective merchant websites into the dictionary, particularly if the prospective merchant becomes a customer of the payment provider (e.g., purchases and/or implements the payment provider's processes). The dictionary may also use historical information for the websites and/or with the payment provider, which may include when merchants became a customer of the payment provider, updates to websites and added/removed content, and other data. The term usage may be country and/or language specific, and may be weighed differently based on the country/language.

Website processing application 160 may pull or retrieve the website data for the website, for example, from a database associated with the website (e.g., database 136 of prospective merchant server 130). In other embodiment, website processing application 160 may instead scrape the data from displayed or retrievable data on the website, for example, from one or more webpages constituting the website (e.g., the website hosted by website application 140 of prospective merchant server 130). Once determined, website processing application 160 may process the website data for prospective merchant server 130 using the website term information to determine services and/or analytics to offer to prospective merchant server 130. For example, based on one or more matching terms, website processing application 160 may determine whether prospective merchant server 130 would be a candidate to utilize one or more services of payment provider server 150, as well as what services prospective merchant server 130 may wish to utilize. Website processing application 160 may also determine a predicted total payment volume based on the appearance of one or more terms and their associated merchants. In various embodiments, a score may also be determined for the website, which may correspond to number of appearance, number of terms, strength of each term, and/or the merchants matching the terms total payment volume and/or used payment services. Other statistics, such as the number of appearances, the ratio appearances to other text and terms, the size, the color, the placement, and/or other information for the term may all be used in the score. In various embodiments, a dedicated application of prospective merchant server 130 may instead be processed against a dictionary of terms for dedicated applications of past and current merchant customers of payment provider server 150. Thus, the dictionary may be platform specific and rely on terms used within the application or website, or may be platform agnostic and rely instead on term usage.

Merchant advertisement application 170 may correspond to one or more processes to execute software modules and associated specialized hardware of payment provider server 150 to generate advertisements and/or message to prospective merchants determined using website processing application 160 of services and analytics, and communicate the messages to the prospective merchants. In this regard, merchant advertisement application 170 may correspond to specialized hardware and/or software to access prospective merchant information determined using website processing application 160. The prospective merchant information may include prospective merchants (e.g., the merchant corresponding to prospective merchant server 130) as well as the total payment volume, potential payment services, and/or other information for the merchant. Merchant advertisement application 170 may generate an advertisement for to prospective merchant server 130 based on the prospective merchant information determined using the merchant's website data and the website term information. The advertisement may generally advertise the services of payment provider server 150 to prospective merchant server 130. In other embodiments, the advertisement may be targeted to the services determined to be useful to prospective merchant server 130. Moreover, the advertisements may also include messages of analytics or other data for the prospective merchant using the website term information. In yet other embodiments, an advertisement response model may be provided to the merchant advertisement application 170, and the merchant advertisement application 170 may be configured to perform a model enhancement process to improve the advertisement response model. The model enhancement process is described in more detail below with reference to FIG. 5 and FIG. 6.

Transaction processing application 152 may correspond to one or more processes to execute software modules and associated specialized hardware of payment provider server 150 to provide payment services to merchant and users, for example though a user's payment account and/or payment instruments. In this regard, transaction processing application 152 may correspond to specialized hardware and/or software to provide payment services, which may be implemented into one or more merchant websites and/or dedicated applications of a merchant. The payment services may allow for a payment to the merchant by a user through a payment instrument, including a credit/debit card, banking account, payment account with payment provider server 150, and/or other financial instrument. In order to establish a payment account for a merchant and/or user to send and receive payments, transaction processing application 152 may receive information requesting establishment of the payment account. The information may include user personal and/or financial information. Additionally, the information may include a login, account name, password, PIN, or other account creation information. The merchant/user may provide a name, address, social security number, or other personal information necessary to establish the account and/or effectuate payments through the account. Transaction processing application 152 may further allow the merchant/user to service and maintain the payment account, for example, by adding and removing payment instruments. Transaction processing application 152 may be used to provide a payment for an item to a merchant, such as current merchant server 110 and/or prospective merchant server 130. Transaction processing application 152 may debit an account of the user automatically and provide the payment to an account of the merchant. Transaction processing application 152 may also be used to provide transaction histories for processed transactions.

In various embodiments, payment provider server 150 includes other applications 154 as may be desired in particular embodiments to provide features to payment provider server 134. For example, other applications 154 may include security applications for implementing server-side security features, programmatic client applications for interfacing with appropriate application programming interfaces (APIs) over network 180, or other types of applications. Other applications 154 may contain software programs, executable by a processor, including a graphical user interface (GUI), configured to provide an interface to the user when accessing payment provider server 150, where the user or other users may interact with the GUI to more easily view and communicate information. In various embodiments, other applications 154 may include connection and/or communication applications, which may be utilized to communicate information to over network 180.

Additionally, payment provider server 150 includes database 156. As previously discussed, the user and/or the merchant corresponding to telecommunication carrier server 170 may establish one or more digital wallets and/or payment accounts with payment provider server 150. Digital wallets and/or payment accounts in database 156 may include user information, such as name, address, birthdate, payment instruments/funding sources, additional user financial information, user preferences, and/or other desired user data. Users may link to their respective digital wallets and/or payment accounts through an account, user, merchant, and/or device identifier. Thus, when an identifier is transmitted to payment provider server 150, e.g. from communication device 130, one or more digital wallets and/or payment accounts belonging to the users may be found. Additionally, database 156 may store data for various websites, as well as process website term information and information on prospective merchant customers for payment provider server 150.

In various embodiments, payment provider server 150 includes at least one network interface component 158 adapted to communicate current merchant server 110 and/or prospective merchant server 130 over network 180. In various embodiments, network interface component 158 may comprise a DSL (e.g., Digital Subscriber Line) modem, a PSTN (Public Switched Telephone Network) modem, an Ethernet device, a broadband device, a satellite device and/or various other types of wired and/or wireless network communication devices including microwave, radio frequency (RF), and infrared (IR) communication devices.

Network 180 may be implemented as a single network or a combination of multiple networks. For example, in various embodiments, network 180 may include the Internet or one or more intranets, landline networks, wireless networks, and/or other appropriate types of networks. Thus, network 180 may correspond to small scale communication networks, such as a private or local area network, or a larger scale network, such as a wide area network or the Internet, accessible by the various components of system 100.

FIG. 2 is a representation of two exemplary merchant website interfaces for use in determining a dictionary of website terms and providing targeted advertisement of payment services, according to an embodiment. Environment 200 includes a merchant website A 1000 corresponding to a current merchant customer website provided by website application 120 executed by current merchant server 110 in environment 100 of FIG. 1. Moreover, environment 200 includes a merchant website B 1100 corresponding to a prospective merchant customer website provided by website application 140 executed by prospective merchant server 130 in environment 100 of FIG. 1.

Merchant website A 1000 may correspond to a website of a current merchant customer of a payment provider that utilizes various shopping, checkout, and/or payment services and features provided by the payment provider. In this regard, merchant website A 1000 includes a webpage A 1002 having data that may include terms used on merchant website A 1000. For example, webpage A 1002 includes a sales portal A 1004 for sales of items. Sales portal A 1004 may include a term A 1006, such as text, logos, banners, images, and/or graphics. Term A 1006 may be included in the website data for merchant website A 1000 as a term used on merchant website A 1000. Sales portal A 1004 may also include an item A 1008 having a term B 1010, a term C 1012, and a term D 1014. Sales portal A 1004 may also include a checkout process A 1016.

Webpage A 1002 may further include payment processes for use with sales portal A 1004. For example, a customer of merchant website A 1000 may utilize payment process A 1018 and/or payment process B 1020. Payment process A 1018 and payment process B 1020 may correspond to payment processes offered by the payment provider. Moreover, in certain embodiments, processes and features of sales portal A 1004 and/or checkout process A 1016 may also be offered by the payment provider. The payment provider may further process data from merchant A information 1022, such as term E 1024 and term F 1026 in various embodiments.

Merchant website B 1100 may correspond to a website of a prospective merchant, which may be a candidate to utilize one or more of the processes or services provided by the payment provider. Thus, the payment provider may process data available from webpage B 1102. For example, webpage B 1102 may include information for sales portal B 1104. Thus, the payment provider may determine that webpage B includes term G 1106, as well as the terms for item A 1008 (e.g., term H 1108, term C 1012, and term D 1014). As term C 1012 and term D 1014 match between webpage A 1002 of the current merchant customer of the payment provider and webpage B 1102 of the prospective merchant customer of the payment provider, the payment provider may determine that merchant website B 1100 may be a prospective customer, may wish to utilize one or more processes or services utilized by merchant website A 1000, and/or may provide analytics on similar current merchant customers. For example, although webpage B 1102 uses checkout process B 1110, webpage B 1102 may better utilize checkout process A 1016. Similarly, although payment process C 1112 is used on webpage B 1102, payment process A 1018 of webpage A 1002 may be better or ideal.

In similar fashion, additional matching information may also be used to provide similarities between merchant website A 1000 and merchant website B 1100. For example, payment process B 1020 is shared between webpage A 1002 and webpage B 1102. In addition, merchant B information for merchant website B 1100 has a new term H 1116, but shares term F 1026 with merchant A information for merchant website A 1000. Thus, additional information and terms may be shared between websites.

FIG. 3 is an exemplary system environment having merchant website servers with data necessary for determining a dictionary of website terms and providing targeted advertisement of payment services, according to an embodiment. FIG. 3 includes current merchant server 110, a prospective merchant server 130, and a payment provider server 150 all discussed in reference to environment 100 of FIG. 1.

Current merchant server 110 executes website application 120 corresponding generally to the specialized hardware and/or software modules and processes described in reference to FIG. 1. In this regard, website application 120 includes information for a website hosted by a current merchant customer of payment provider server 150. For example, website information 2000 may be utilized with the website. Website information 2000 may include data that may be extracted or determined by payment provider server 150. Thus, website information 2000 includes website terms 2002. Website information 2000 may also include merchant information 2004 and sales information 2006, such as checkout processes 20008 and payment processes 2010.

Similarly, prospective merchant server 130 executes website application 140 corresponding generally to the specialized hardware and/or software modules and processes described in reference to FIG. 1. In this regard, website application 140 includes information for a website hosted by a prospective merchant customer of payment provider server 150. Website information 2100 may be processed by payment provider server 150 to provide services and analytics to the prospective merchant customer. Website information similarly includes website terms 2102 used to match to website terms 2002 of current merchant server 110. Additionally, merchant information 2104 and sales information 2106 having checkout processes 2108 and payment processes 2110 may be matched to merchant information 2004 and sales information 2006 of current merchant server 110. In various embodiments, payment provider server 150 may offer changes and upgrades to sales information 2106, such as new checkout and/or payment processes.

Payment provider server executes website processing application 160 and merchant advertisement application 170 corresponding generally to the specialized hardware and/or software modules and processes described in reference to FIG. 1. In this regard, website processing application 160 may process website information 2000 and website information 2100. For example, website information 2100 may be included in retrieved website information 2200, which may also include website terms 2102 for website information 2100. Website term information 2202 includes information processes from a plurality of current merchant customer of payment provider server 150, such on the websites of the current merchant customers. Thus, website term information 2202 includes website information 2000 in stored websites and terms 2204. Stored websites and terms 2204 further includes associated services 2206 for the services provided by the websites in stores websites and terms 2204. Using the aforementioned information, website processing application 160 may determine matching website information 2208, which may include matching terms 2210.

Merchant advertisement application 170 may be used to provide advertisements and/or messages based on matching website information 2208. For example, merchant advertisement application 170 includes determined advertisements 2300, such as advertisement A 2302. Advertisement A 2302 may include matching terms 2210. Moreover, advertisement A 2302 includes information offered to a prospective merchant, such as offered services 2304 and/or offered information 2306 (e.g., merchant analytics).

FIG. 4 is a flowchart of an exemplary process for predicting merchant behavior using merchant website terms, according to an embodiment. Note that one or more steps, processes, and methods described herein may be omitted, performed in a different sequence, or combined as desired or appropriate.

At step 402, merchant website data for a website of a merchant is retrieved, by a payment provider system that comprises one or more hardware processors coupled to a non-transitory memory, merchant website data for a website of a merchant, wherein the merchant website data comprises merchant website terms on the website of the merchant. The merchant website data may be for a plurality of merchant webpages constituting the website of the merchant. The merchant website data may comprise text used by the merchant on the plurality of merchant webpages. The merchant website data may also include text on the plurality of merchant webpages by at least one customer of the merchant in a forum, website postings, messages, and requests on the plurality of merchant webpages. The merchant website data may further comprise a text size, a color, a font, a sequence of terms, a ratio of a term to other terms, and a type of merchant for the merchant. The website of the merchant may be one of a mobile website type, a dedicated application website type, and a traditional website type, wherein the website term information is particular to one of the mobile website type, the dedicated application website type, and the traditional website type.

Website term information is accessed, from the non-transitory memory, wherein the website term information comprises a plurality of terms appearing on a plurality of merchant websites for a plurality of merchants, at step 404. For example, the plurality of merchants may comprise previous customers and current customers of the payment provider system utilizing at least one service provided by the payment provider system. Thus, the merchant may comprise a prospective customer of the payment provider system. In various embodiments, the website term information is determined using the plurality of merchant websites for the plurality of merchants, wherein the website term information is determined based on occurrences of the plurality of terms on the plurality of merchant websites and current payment processing services utilized by each of the plurality of merchants.

Moreover, each of the plurality of terms in the website term information may further be associated with a weighted score based on an importance for the each of the plurality of terms being found on the merchant website when determining the advertisement. For example, the weighted score for the each of the plurality of terms may be determined based on payment processing services used by the plurality of merchants and the plurality of terms occurring on each of the plurality of merchant websites. At least one of the merchant website terms on the website of the merchant is determined to match at least one of the plurality of terms in the website term information, at step 406. For example, the merchant may be linked to at least one of the plurality of merchants based on the merchant website terms and the plurality of terms.

At step 408, an advertisement for a payment processing service provided by the payment provider system is determined based on the at least one of the merchant website terms matching the at least one of the plurality of terms. In various embodiments, the merchant website data includes a number of occurrences for each of the merchant website terms on the website of the merchant, wherein the advertisement is further determined based on the number of occurrences. In further embodiments, a total score for the website of the merchant may be determined using the score associated with each of the plurality of terms, wherein at least one of the advertisement and the payment processing service is further determined using the total score. For example, the total score may be used to determine a prediction comprising at least one of a merchant size, payment sizes for payments to the merchant, payment volume for the payments to the merchant, and a customer type. Thus, at least one of the advertisement and the payment processing service is determined using the prediction.

The advertisement is communicated to the merchant, at step 410. The payment processing service in the advertisement may comprise a payment process for merchant customers to provide payments to the merchant, a website payment flow for the website of the merchant, a payment account service with the payment provider system, and a checkout process on the website of the merchant. The payment processing service may be implemented in the website of the merchant if the merchant accepts the advertisement. In various embodiments, the process may further include updating the website term information with the merchant website terms if the merchant accepts the payment processing service, wherein the merchant website terms are associated with the payment processing service. Thus, at least one new merchant website to retrieve additional merchant website data from may be determined based on the updated website term information.

FIG. 5 is a block diagram of a networked system 200 that includes the payment provider server 150, a user computer 502 and a prospective user computer 504. System 200 may comprise or implement a plurality of devices, servers, and/or software components that operate to perform various methodologies in accordance with the described embodiments. Exemplary devices and servers may include device, stand-alone, and enterprise-class servers, operating an OS such as a MICROSOFT® OS, a UNIX® OS, a LINUX® OS, or other suitable device and/or server based OS. It can be appreciated that the devices and/or servers illustrated in FIG. 2 may be deployed in other ways and that the operations performed and/or the services provided by such devices and/or servers may be combined or separated for a given embodiment and may be performed by a greater number or fewer number of devices and/or servers. One or more devices and/or servers may be operated and/or maintained by the same or different entities.

The user computer 502 and the prospective user computer 504 may each include one or more processors, memories, and other appropriate components for executing instructions such as program code and/or data stored on one or more computer readable mediums to implement the various applications, data, and steps described herein. For example, such instructions may be stored in one or more computer readable media such as memories or data storage devices internal and/or external to various components of system 200, and/or accessible over network 180. In certain embodiments, the user computer 502 may include the current merchant server 110, and the prospective user computer 504 may include the prospect merchant server 130. In other embodiments, the user computer 502 may include various other computers and electronic devices associated with users of the payment provider. Similarly, the prospective computer 504 may include various other computers and electronic devices associated with prospective users of the payment provider. As used herein, a “prospective user” may refer to an entity (e.g., a person, consumer, merchant, and/or the like) that is not yet a user of the payment provider.

As illustrated in FIG. 5, the user computer 502, the prospective user computer 504, and the payment provider server 150 may be in communication via the network 180. Further, the payment provider server 150 may include an advertisement modeling application 510. As described more fully below, the advertisement modeling application 510 may be provided an advertisement response model. The advertisement response model may include, but is not limited to classification algorithms such as AdaBoost classifier, logistic regression, support vector machines, gradient boosting classifier, Isolation Forest, linear discriminant analysis, neural networks (e.g., multi-layer perceptron), decision trees classifier, Random Forest classifier, naïve Bayesian classifier, and Bagging classifier. The advertisement modeling application 510 may improve the advertisement response model using a model enhancement process. The advertisement response model may facilitate a selection of which users of the user computers 502 and which prospective users of the prospective user computers 504 to target with respect to an advertising campaign. In implementations where certain selected users and/or prospective users correspond to merchant and/or prospective merchants, the advertisement modeling application 510 may communicate with the merchant advertisement application 170 to transmit advertisements to the corresponding current merchant server(s) 110 and/or prospective merchant servers 130.

FIG. 6 depicts a flow chart of a method 600 for performing a model enhancement process that improves an advertisement response model in accordance with one or more particular embodiments. As previously discussed, the advertisement response model may be configured to predict the responses of units included in a target data set to a particular advertising campaign. Further, it will be appreciated that while the method 600 may be described as being performed by the merchant advertisement application 170, the method 600 may also be performed by other applications 154 of the payment provider server 150 or by another application included in another computing device, or a combination thereof. Note that one or more steps, processes, and methods described herein may be omitted, performed in a different sequence, or combined as desired or appropriate.

At step 602, a training data set may be generated. In certain implementations, the training data set may have been previously generated, such as by a data gather device (not illustrated), and may be provided to the advertisement modeling application 510. In other embodiments, the training data set may be generated, such as by the advertisement modeling application 510. For example, the advertisement modeling application 510 may generate the training data set based on a run of the advertising campaign with respect to a random sampling of a particular data set. As such, the responses of each unit of the random sampling to the advertising campaign may be stored in the training data set. It will be appreciated that other methods of generating the training data set are also contemplated. Furthermore, in some embodiments, the target data set, the training data set, and the particular data set may be different from each other.

At step 604, the advertisement modeling application 510 may execute the advertisement response model using the training data set. In other words, the advertisement response model may be trained by the training data set. At step 606, the advertisement modeling application 510 may calculate a accuracy value associated with the advertisement response model. The advertisement modeling application 510 may determine whether the calculated accuracy value meets (e.g., reaches or exceeds) a accuracy value threshold. The accuracy value may measure an ability of the advertisement response model to accurately predict how particular users or prospective users would respond to the advertising campaign. In certain embodiments, a higher accuracy value may indicate a greater accuracy in predictions by the advertisement response model. According to a particular embodiment, the accuracy value may be calculated using predictive entropy. However, it will be appreciated that various other algorithms may also be used calculate the accuracy value. For example, in certain embodiments, the accuracy value may be calculated as part of executing the advertisement response model.

If the accuracy value does not meet the score threshold, the method 600 may proceed to step 608. At step 608, the advertisement modeling application 510 may execute the advertisement response model using the target data set. In certain implementations, executing the advertisement response model at step 608 may include testing the advertisement response model using the target data set. Further, at step 610, the advertisement modeling application 510 may determine certainty scores associated with the target data set. According to a particular embodiment, the advertising modeling application 510 may determine a respective certainty score for each unit in the target data set. Further, the certainty scores may be calculated using various algorithms, such as Stochastic Gradient Descent. and may be calculated as part of executing the advertisement response model.

At step 612, based on the certain scores, the advertisement modeling application 510 may determine a subset of the target data set for which to run the advertising campaign. For example, the advertisement modeling application 510 may rank the units in the target data set according to their respective certainty scores. As such, the subset of the target data set may include a predetermined number of lowest ranked units from the target data set. In other words, the remaining units in the target data set that are not in the subset may each have a corresponding certainty score that is greater than each of the certainty scores corresponding to the units included in the subset. In other examples, each unit included in the subset of the target data set may have corresponding certainty scores below a certainty score threshold to be included in the sub set.

In certain implementations, the certainty score for a particular unit may indicate a degree of certainty corresponding to the advertisement response model's prediction as to how the particular unit would respond to the advertising campaign. For instance, a first unit having a first certainty score that is greater than a second certainty score of a second unit may indicate that the advertisement response model is more certain about the first unit's predicted response to the advertising campaign than the second unit's predicted response to the advertising campaign.

Moreover, one or more units of the subset of the target data may be associated with certain characteristics. For example, the subset of the target data may be associated with particular merchant characteristics that include particular website terms. Thus, using this example, the subset may indicate the advertisement response model is relatively uncertain how merchants (who use the particular website terms on their websites) would respond to the advertising campaign. It will be appreciated that other characteristics may also be associated with the units of the subset, including but not limited to characteristics that relate to demographics, geographic location, buying habits, other website data, products and services being offered, and/or the like.

According to a particular embodiment, subsequent to determining the subset of the target data set, the units included in the subset may be removed from the target data set. Further, a run of the advertising campaign may be conducted with respect to the units included in the subset. For example, one or more advertisements may be transmitted (e.g., by the merchant advertisement application 170 and/or the advertisement modeling application 510) to the user computer(s) 502 and the prospective user computer(s) 504.

At step 614, one or more responses to the run of the advertising campaign with respect to the subset may be received by the advertisement modeling application 510. As a result, each unit of the subset may be associated with a response type. For example, response types may include positive responses and negative responses. A positive response associated with a particular unit may indicate that the particular unit responded to the advertising campaign by purchasing a product or service offered by the advertising campaign. In other words, the particular unit is “converted” by the advertising campaign. It will be appreciated that other criteria for indicating a positive response are also possible, such as simply receiving an inquiry from the particular unit about the product or service. A negative response associated with the particular unit may indicate that the particular units did not purchase the product or service offered by the advertising campaign. It will be appreciated that other criteria for indicating a negative response are also possible, such as not receiving a response to the advertising campaign from the particular unit within a predetermined time frame.

At step 616, the advertisement modeling application 510 may update the training data set with the subset and the associated responses to the advertising campaign. In certain embodiments, updating the training data set may include adding the subset and the associated responses to the training data set. In other embodiments, updating the training data set may include generating a new training data set that includes the training data set and the subset (and associated responses).

Subsequent to updating the training data set, the method 600 may proceed back to step 604. Thus, steps 604-616 may be repeated until a accuracy value of the advertisement response model meets or exceeds the accuracy value threshold in step 606. If the accuracy value meets or exceeds the accuracy value threshold, the method 600 may proceed to step 618. In this manner, the training data set may be continuously updated, and the advertisement response model may be iteratively trained and improved.

At step 618, the advertisement modeling application 510 may execute the advertisement response model using the remaining units in the target data set. For instance, as described above with respect to the step 612, one or more units in the target data set may have been removed, since responses to the advertising campaign by the units in the identified subsets may already be known.

At step 620, based on executing the advertisement response model using the target data set, the advertisement modeling application 510 may identify which units in the target data set to target with respect to the advertising campaign. For instance, the advertisement response model may indicate that one or more of the remaining units in the target data set correspond to a positive predicted response to the advertising campaign. As such, the advertisement modeling application 510 may select the one or more of the remaining units to target with respect to the advertising campaign.

As previously discussed, the method 600 enables iterative improvements to the advertisement response model by updating the training data set with targeted subsets of the target data set. For example, during each iteration (e.g., of steps 604-616) the advertising campaign may be run against identified units in the target data set for which the advertisement response model is relatively uncertain. As such, this uncertainty is mitigated by obtaining the identified units' actual responses to the advertising campaign. The training data set is then updated and improved in the following iteration using the obtained responses of the identified units, which in turn improves the training of the advertisement response model.

FIG. 7 is a block diagram of a computer system suitable for implementing one or more components in FIG. 1 and FIG. 5, according to an embodiment. In various embodiments, the communication device may comprise a personal computing device (e.g., smart phone, a computing tablet, a personal computer, laptop, a wearable computing device such as glasses or a watch, Bluetooth device, key FOB, badge, etc.) capable of communicating with the network. The service provider may utilize a network computing device (e.g., a network server) capable of communicating with the network. It should be appreciated that each of the devices utilized by users and service providers, including the current merchant server 110, the prospective merchant server 130, the payment provider sever 150, the user computer 502, and the prospective user computer 504, may be implemented as computer system 700 in a manner as follows.

Computer system 700 includes a bus 702 or other communication mechanism for communicating information data, signals, and information between various components of computer system 700. Components include an input/output (I/O) component 704 that processes a user action, such as selecting keys from a keypad/keyboard, selecting one or more buttons, image, or links, and/or moving one or more images, etc., and sends a corresponding signal to bus 702. I/O component 704 may also include an output component, such as a display 711 and a cursor control 713 (such as a keyboard, keypad, mouse, etc.). An optional audio input/output component 705 may also be included to allow a user to use voice for inputting information by converting audio signals. Audio I/O component 705 may allow the user to hear audio. A transceiver or network interface 706 transmits and receives signals between computer system 700 and other devices, such as another communication device, service device, or a service provider server via network 180. In one embodiment, the transmission is wireless, although other transmission mediums and methods may also be suitable. One or more processors 712, which can be a micro-controller, digital signal processor (DSP), or other processing component, processes these various signals, such as for display on computer system 700 or transmission to other devices via a communication link 718. Processor(s) 712 may also control transmission of information, such as cookies or IP addresses, to other devices.

Components of computer system 700 also include a system memory component 714 (e.g., RAM), a static storage component 716 (e.g., ROM), and/or a disk drive 717. Computer system 700 performs specific operations by processor(s) 712 and other components by executing one or more sequences of instructions contained in system memory component 714. Logic may be encoded in a computer readable medium, which may refer to any medium that participates in providing instructions to processor(s) 712 for execution. Such a medium may take many forms, including but not limited to, non-volatile media, volatile media, and transmission media. In various embodiments, non-volatile media includes optical or magnetic disks, volatile media includes dynamic memory, such as system memory component 714, and transmission media includes coaxial cables, copper wire, and fiber optics, including wires that comprise bus 702. In one embodiment, the logic is encoded in non-transitory computer readable medium. In one example, transmission media may take the form of acoustic or light waves, such as those generated during radio wave, optical, and infrared data communications.

Some common forms of computer readable media include, for example, floppy disk, flexible disk, hard disk, magnetic tape, any other magnetic medium, CD-ROM, any other optical medium, punch cards, paper tape, any other physical medium with patterns of holes, RAM, PROM, EEPROM, FLASH-EEPROM, any other memory chip or cartridge, or any other medium from which a computer is adapted to read.

In various embodiments of the present disclosure, execution of instruction sequences to practice the present disclosure may be performed by computer system 500. In various other embodiments of the present disclosure, a plurality of computer systems 500 coupled by communication link 518 to the network (e.g., such as a LAN, WLAN, PTSN, and/or various other wired or wireless networks, including telecommunications, mobile, and cellular phone networks) may perform instruction sequences to practice the present disclosure in coordination with one another.

Where applicable, various embodiments provided by the present disclosure may be implemented using hardware, software, or combinations of hardware and software. Also, where applicable, the various hardware components and/or software components set forth herein may be combined into composite components comprising software, hardware, and/or both without departing from the spirit of the present disclosure. Where applicable, the various hardware components and/or software components set forth herein may be separated into sub-components comprising software, hardware, or both without departing from the scope of the present disclosure. In addition, where applicable, it is contemplated that software components may be implemented as hardware components and vice-versa.

Software, in accordance with the present disclosure, such as program code and/or data, may be stored on one or more computer readable mediums. It is also contemplated that software identified herein may be implemented using one or more general purpose or specific purpose computers and/or computer systems, networked and/or otherwise. Where applicable, the ordering of various steps described herein may be changed, combined into composite steps, and/or separated into sub-steps to provide features described herein.

The foregoing disclosure is not intended to limit the present disclosure to the precise forms or particular fields of use disclosed. As such, it is contemplated that various alternate embodiments and/or modifications to the present disclosure, whether explicitly described or implied herein, are possible in light of the disclosure. Having thus described embodiments of the present disclosure, persons of ordinary skill in the art will recognize that changes may be made in form and detail without departing from the scope of the present disclosure. Thus, the present disclosure is limited only by the claims. 

1. (canceled)
 2. A system, comprising: at least one processor; and at least one memory storing computer-executable instructions, that in response to execution by the at least one processor, causes the system to perform operations comprising executing an advertisement response model using a first training data set, wherein the first training data set indicates, for each unit included in the training data set, a respective response to an advertising campaign; determining, based on the executing the advertisement response model using the first training data set, that a first accuracy value corresponding to the advertisement response model is less than a accuracy value threshold; calculating, based on executing the advertisement response model using a target data set that is different from the first training data set, a respective certainty score corresponding to each unit of the target data set; determining, based on the respective certainty score corresponding to each unit of the target data set, a subset of the target data set for which to run the advertising campaign; receiving one or more responses corresponding to a run of the advertising campaign with respect to the subset of the target data set, and generating a second training data set based on the one or more responses; and determining, based on executing the advertisement response model using the second training data set, whether a second accuracy value corresponding to the advertisement response model is greater than the accuracy value threshold.
 3. The system of claim 2, wherein the operations further comprise: determining that the second accuracy value is greater than or equal to the accuracy value threshold; adjusting the target data set by removing the units included in the subset from the target data set; and based on executing the advertisement response model with respect to the adjusted target data set, determining one or more units of the adjusted target data set that have a positive predicted response to the advertising campaign.
 4. The system of claim 2, wherein the operations further comprise removing the subset of the target data set from the target data set.
 5. The system of claim 2, wherein determining the subset of the target data set comprises: ranking each unit of the target data set according to the respective certainty score for each unit of the target data set, wherein the subset includes a predetermined number of units from the target data set that are each associated with a lower respective certainty score than respective certainty scores of remaining units in the target data set that are not included in the sub set.
 6. The system of claim 2, wherein each unit of the subset of the target data set is associated with a certainty score that is less than a certainty score threshold.
 7. The system of claim 2, wherein the operations further comprise generating the first training data set by transmitting advertisements corresponding to the advertising campaign to respective devices of a random sample of a particular population.
 8. The system of claim 2, wherein the subset of the target data corresponds to one or more characteristics selected from a group comprising website characteristics, geographic location characteristics, and demographic characteristics.
 9. The system of claim 2, wherein the second accuracy value is greater than the first accuracy value.
 10. A method comprising: executing an advertisement response model using a first training data set, wherein the first training data set indicates, for each unit included in the training data set, a respective response to an advertising campaign; determining, based on the executing the advertisement response model using the first training data set, that a first accuracy value corresponding to the advertisement response model is less than a accuracy value threshold; calculating, based on executing the advertisement response model using a target data set that is different from the first training data set, a respective certainty score corresponding to each unit of the target data set; determining, based on the respective certainty score corresponding to each unit of the target data set, a subset of the target data set for which to run the advertising campaign; receiving one or more responses corresponding to a run of the advertising campaign with respect to the subset of the target data set, and generating a second training data set based on the one or more responses; and determining, based on executing the advertisement response model using the second training data set, whether a second accuracy value corresponding to the advertisement response model is greater than the accuracy value threshold.
 11. The method of claim 10, further comprising: determining that the second accuracy value is greater than or equal to the accuracy value threshold; adjusting the target data set by removing the units included in the subset from the target data set; and based on executing the advertisement response model with respect to the adjusted target data set, determining one or more units of the adjusted target data set that have a positive predicted response to the advertising campaign.
 12. The method of claim 10, further comprising: removing the subset of the target data set from the target data set.
 13. The method of claim 10, wherein determining the subset of the target data set comprises: ranking each unit of the target data set according to the respective certainty score for each unit of the target data set, wherein the subset includes a predetermined number of units from the target data set that are each associated with a lower respective certainty score than respective certainty scores of remaining units in the target data set that are not included in the subset.
 14. The method of claim 10, wherein each unit of the subset of the target data set is associated with a certainty score that is less than a certainty score threshold.
 15. The method of claim 10, further comprising: generating the first training data set by transmitting advertisements corresponding to the advertising campaign to respective devices of a random sample of a particular population.
 16. The method of claim 10, wherein the subset of the target data corresponds to one or more characteristics selected from a group comprising website characteristics, geographic location characteristics, and demographic characteristics.
 17. The method of claim 10, wherein the second accuracy value is greater than the first accuracy value.
 18. A non-transitory machine-readable medium having stored thereon machine-readable instructions executable to cause a machine to perform operations comprising: executing an advertisement response model using a first training data set, wherein the first training data set indicates, for each unit included in the training data set, a respective response to an advertising campaign; determining, based on the executing the advertisement response model using the first training data set, that a first accuracy value corresponding to the advertisement response model is less than a accuracy value threshold; calculating, based on executing the advertisement response model using a target data set that is different from the first training data set, a respective certainty score corresponding to each unit of the target data set; determining, based on the respective certainty score corresponding to each unit of the target data set, a subset of the target data set for which to run the advertising campaign; receiving one or more responses corresponding to a run of the advertising campaign with respect to the subset of the target data set, and generating a second training data set based on the one or more responses; and determining, based on executing the advertisement response model using the second training data set, whether a second accuracy value corresponding to the advertisement response model is greater than the accuracy value threshold.
 19. The non-transitory machine-readable medium of claim 18, further comprising: determining that the second accuracy value is greater than or equal to the accuracy value threshold; adjusting the target data set by removing the units included in the subset from the target data set; and based on executing the advertisement response model with respect to the adjusted target data set, determining one or more units of the adjusted target data set that have a positive predicted response to the advertising campaign.
 20. The non-transitory machine-readable medium of claim 18, further comprising: removing the subset of the target data set from the target data set.
 21. The non-transitory machine-readable medium of claim 18, wherein the subset of the target data corresponds to one or more characteristics selected from a group comprising website characteristics, geographic location characteristics, and demographic characteristics. 